"예산이 없는데 어쩔껴..."
그러자 이순신이 말했다.
"신에게는 아직 12척의 가상 머신이 있사옵니다."
"대강 50K TPS정도는 뽑아야 할꺼요.."
"...뭥미???...??"
자세한 내용을 쓰기는 좀 그렇고, 레디스나 멤캐시 자원도 빈약한데다가 HA를 생각하면 아주 골아픈 상황이다.
자세한 내용을 쓰기가 좀 그러하니 바로 소개 들어갑니다.
메모리가 없으면 쿠키를 먹으면 파일을 쓰면 될텐데. 덩치큰 공룡 DBM은 성능이 못 따라오고, 경량 파일 저장소는 직접 구현해볼 법도 하지만 그만해 미친놈아. 그리하여 키-밸류 기반의 빠른 파일 디비를 생각했다. 이렇게 저렇게 해서 매시로 범벅된 클러스터링이나 돈으로 바른 짱짱머신 마스터-슬레이브가 아니라 분산-독립형(=일당백 아키텍쳐)으로 맨들어 보려는 참이다.
그리하여 간만에10년만에 구닥다리20년쯤 된 버클리 디비를 깠다.. 예제로 좀 삽질하고보니 이건 아닌 것 같은 느낌적 느낌이 들었습니다.
메모리가 없어서 파일을 쓰는 것인데, 하드마저도 적다. 신에게는 12척의.. 여튼.. 메모리 대신 파일을 캐시처럼 쓴다는 목적 하에서는 하드 잠식이 일어난다. 레디스나 멤캐시를 쓰면 ttl 처리하면 될 일이지만 ttl 체킹이 없는 경량 파일 디비에서는 문제가 있다.
파티셔닝 기능이 있다면 시간 값으로 파티셔닝을 해서 주기적으로 파티션을 지우는 방법을 모색해 볼 수 있겠다. 파티셔닝을 지원하지 않으니 생각한 것은 버클리 디비의 큐 기능이다. 큐(ttl 처리)와 트리(메인 디비)를 쌍으로 두고, 큐에 시간 값을 키로 트리의 키를 값으로 쭉쭉 밀어넣고 10초마다 뭐 get 일어날 때 마다 체킹해서 큐 대가리에서 죽죽 뽑고 트리에서 지우는 방식. 하.. 드럽긴 한데 키밸류 파일 디비가 워낙 빠르니 해 볼만 했다.
버클리 디비는 나랑 궁합이 안 맞는 것 같다.
이런 저런 것을 찾아보면서 손가락 빨고 있으니 LevelDB가 자주 회자되네??
나는 솔직히 그의 위엄에 대해 잘은 모르는데 구전으로 전해지는 전설들을 줏어들은 바는 있다. 어써에 제프딘이 있다. 제프딘이라고!. 묻지도 따지지도 맙시다.
여튼 파일 기반의 키밸류 저장소이다. 싱글 인스턴스이며 제프딘이라니까 고속이고 키밸류 아토믹 처리를 해 준다고 써 있음. 그런데 TTL은 지원하지 않는다. 당연히 그런 용도가 아니니까. 뜯어고쳐 볼까? 미친놈아 니가 제프딘 코드를 어찌 만져..
여기까지 당도했다. 레디스 인터페이스로 TTL 처리를 해 주는데, 뒤에다 LevelDB를 세워둘 수 있다. 마스터 슬레이브 구성까지 해주니 금상첨화. 이제 파일 기반 캐시 팜을 구축 할 수 있는 것이다. 같이 넣고 빌드해서 함수 콜로 사용하는 것보다야 수십 배 느려지겠지만서도 이번 목표에는 인수인계가 쉬운 아키텍쳐를 짜서 유사시 이직하기 쉽게 씨 프로그래머가 없어도 돌릴 수 있는 구조로 만들자는 목표도 있으므로..
시킨대로 하면 잘 안 되는데 su 때리고 하세요. golang, libtool, cmake 등은 깔아야 합니다.
레디스 처럼 쓰면 된다.
내 컴에서 슬레이브 하나 다른 포트로 꽂아둔 상황. 동접 50
set: 16.567583ms 16.567 micros/op, 60358.83op/s
get: 4.576413ms 4.576 micros/op, 218511.75op/s
randget: 5.460089ms 5.460 micros/op, 183147.20op/s동접 1000
set: 1.09941185s 1099.411 micros/op, 909.58op/s
get: 1.221512523s 1221.512 micros/op, 818.66op/s
randget: 1.227491467s 1227.491 micros/op, 814.67op/s12척으로는 힘들것지만 잘 짜면 뭐 해볼만한 것 같다.
끄읏~